fix(subtreevalidation): nil-check subtree before deleting orphans#771
fix(subtreevalidation): nil-check subtree before deleting orphans#771ordishs wants to merge 2 commits intobsv-blockchain:mainfrom
Conversation
|
🤖 Claude Code Review Status: Complete Summary: The fix correctly addresses issue #4570 by adding nil-checks before dereferencing Findings: [Minor] Missing documentation for GetSubtreeExists Positive observations:
|
Benchmark Comparison ReportBaseline: Current: Summary
All benchmark results (sec/op)
Threshold: >10% with p < 0.05 | Generated: 2026-04-28 19:07 UTC |
…lock_subtrees (refs #4570)
|


Closes #4570.
Summary
subtreesHandlercallsValidateSubtreeInternal, which legitimately returns(nil, nil)when the subtree already exists in the store (a race betweenTryLockIfFileNotExistsand another goroutine completing the write). The handler then panicked onsubtree.Nodes. Severity HIGH because any concurrent subtree-write race can crash the goroutine.Fix
Insert a
if subtree == nil { return nil }between the error check and the orphan-deletion loop. Matches the audit's prescribed shape and mirrors the existing guard inServer.CheckSubtree(line 802).This PR also implements the previously stubbed
GetSubtreeExistsso it actually consultssubtreeStore.Existsfor the subtree file. Without this, the(nil, nil)race path documented in the audit was unreachable - so the regression test could not exercise the bug. Now the existence check works as the comments described and the new defensive guard is properly covered.Test plan
TestSubtreesHandler_NilSubtree) drives the handler down the(nil, nil)return path; asserts no panic and no error.go test -race ./services/subtreevalidation/...passes (241s).